There are many reasons for testing biological fluids. For example, the donation of blood typically requires that the blood be screened for various diseases and/or foreign bodies. Blood screening of donors at blood banks is a large and ever growing market requiring accurate and reliable testing. Other biological fluids, such as urine and saliva, are routinely tested and/or screened to detect diseases, chemicals or other substances.
Over the years, as both the amount of blood being donated and the number of required tests have increased, a degree of automation has occurred. Systems such as the Commander System.TM. by Abbott Laboratories, have partially automated many of the steps involved in blood testing.
The Commander System.TM. can be divided into four main parts: a Flexible Pipetting Center (FPC) which transfers samples to test wells in sample trays, a Parallel Processing Center (PPC) which adds reagents and reads optical absorption test results, a Dynamic Incubator (DI) which incubates the samples, and a Data Management System (DMS) which stores the test results for access by other programs. Under this system, a donor's blood sample is initially bar coded. This information is stored in a local database with the same information residing in the DMS database. The bar coded samples are then transferred to the FPC for pipetting into test wells. The bar coded blood samples have their exact well position in the holding tray entered into the database. This position information is supplied by the FPC in pipetting the samples and is used by the PPC and DMS.
Each holding tray is also bar coded. This bar code is read as soon as the tray is placed into the FPC. The bar code information on the tray, combined with the bar code information on each blood sample, provides for accurate data gathering and tracking of the blood samples through the testing process.
Next, the tray containing the samples moves either to the DI or to the PPC, depending upon the tests being run. As an example, assume the tray moves next to the PPC, the bar code of the tray is again read, to insure tracking of each individual blood sample contained in the test wells. A connection, such as a serial data connection, links the FPC to the PPC to track the blood sample through the entire testing procedure. The PPC reads the test results. The test results, which are linked to a particular blood sample by way of the bar code, are then ported over to the DMS via, for example, a serial data connection.
The DMS takes the information provided to it from the PPC to provide a report of the test results for each blood sample.
In the example of the Commander System.TM., the system components are linked by a communication interface which allows for a continuous "chain-of-custody" to be established for the tested samples. This is illustrated in FIG. 1a, in which, pipettor 110 passes its information along to reader 112 which, in turn, passes a complete package of test information to database 114.
Because many vendors produce biological fluid testing instruments, however, multi-vendor testing environments are commonplace. FIG. 1b illustrates a possible configuration, where a pipettor 120 and a PPC 122 are not compatible and, hence, not linked by a communication interface. In this case, pipettor 120 passes its information to database 114 where it is temporarily stored. Subsequently, PPC 122 requests the pipettor information from database 114 via a special driver; links the test results, which were obtained by reading the sample tray, with the pipettor information; and passes the complete package back to database 114.
In systems of this type, in order to accommodate the numerous system configurations that may arise, database 114 desirably interfaces with a variety of potential sources of test information.
FIG. 2 shows an example of a data interface for the database 114 of FIG. 1a. In FIG. 2, reader 210 sends test information to driver 212 which handles the communication interface and completed receipt of the test information. The test information is then processed by demon 214 which parses the data file and enters it into database 114. The word "demon" as used herein means a process running on one of the computer systems which are coupled to the system. Although the term as it is used in the art typically designates a background process which does not terminate, the present usage of the word is not so limited.
In the system shown in FIG. 2, the reader 210 can be one of several different instruments. Examples of such include a PPC.TM., a Quantum II.TM., a Quantumatic.TM. or a VP.TM. all made by Abbott Laboratories.
FIG. 3 shows an example interface used for the system configuration of FIG. 1b in which pipettor 310 supplies information to database 114. The interface of FIG. 3, similar to that of FIG. 2, uses a separate driver 312 and demon 314 combination for each pipettor supplying information. However, in FIG. 2, the information is only temporarily stored in database 114 until it is requested by PPC 122 (FIG. 1b). The pipettor information is then transferred via a special driver, PPC.sub.-- com 318, to PPC 122 which reads and delivers a complete test information package to database 114 via the interface configuration of FIG. 3.
The requirement that different drivers and demons be created and used for each new system configuration is complicated, time-consuming and impedes the efficient development and integration of multi-vendor testing environments.